software craftsmanship

ソフトウェアの職人魂

テーゼ

アンチテーゼ

『継続的デリバリーのソフトウェア工学』

software craftsmanship では不十分

ソフトウェアクラフトマンシップという考え方はかつて重要でした。この考え方のおかげで、以前の製造重視で儀式的な開発アプローチから重要な一歩を踏み出せたのです。私は、ソフトウェアクラフトマンシップという考え方が間違っているとは思っていません。それでは不十分だと思っているのです。

ref. 第2章

対案

KPI: 安定性とスループット

ref. 『LeanとDevOpsの科学［Accelerate］』

類書

Manifesto

Raising the bar.

本文

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

Not only working software,

but also well-crafted software

Not only responding to change,

but also steadily adding value

Not only individuals and interactions,

but also a community of professionals

Not only customer collaboration,

but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

programmerもstakeholderである

code base のためにできることを代弁できる。

義務があり、責任がある。

cf. 構造の価値

機能分割

構造化プログラミングの第三の柱

批評

クラフトマンシップが人間関係のスキルを軽視して裂け目を悪化させるのではないかと危惧しています。

ビジネスと開発の分断 = 運命の裂け目

数年前、私はEric Evansの観察に感銘を受けました。 それは、開発者はシニアになればなるほど、技術的な問題にフォーカスする傾向があり、 自分たちが働いているドメインを理解しようとしなくなる、というものです。 ドメイン駆動設計はそれを変えようとするものなのですが、 リポジトリにおけるDIの使い方のような議論に矮小化されがちです。